1. Technical Field
The present invention relates generally to relational database tools and in particular to tools for developing and maintaining relational database. Still more particularly, the present invention relates to providing and viewing entity relationship diagrams for development and maintenance of relational databases.
2. Description of the Related Art
Relational databases represent all information as tables, and therefore consist of collections of tables having rows and columns. Each (horizontal) row describes an occurrence of an entity (e.g., a part, a company, etc.), while each (vertical) column describes a characteristic of the entity (e.g., part number, cost, etc.). Each row within a given table is uniquely identified by the values in one or more of the columns.
Entity relationship diagrams are graphs depicting the links between tables in a relational database. FIG. 4 is an example of a traditional, paper-based entity relationship diagram. Several graphical conventions are employed to convey functional information regarding the entity relationships depicted. Boxes 402 and 408 with rounded corners indicate that the table has a dependent relationship with another table--i.e., is a child table. Boxes 406 and 404 with square corners indicate that the table is independent. Independent tables may be related to other tables--i.e., may be parent tables.
The table headers depicted for table boxes 402, 404, 406, and 408 indicate which columns of the table are used as the primary key for the table. Solid lines 410 and 412 connected two table boxes indicates a mandatory relationship between the two tables, required for referential integrity. Dotted line 414 indicates an optional relationship between the two connected tables. Dot connection terminators 416, 418, and 420 identify the child table in a parent-child table relationship, while diamond connection terminator 422 indicates that the parent table may have a NULL in the identifying column for the child table.
Connection 424 describes a sub-type relationship, which is helpful in modelling tables which may have similar columns but not identical sets of the same columns. For example, a table called VEHICLE might contain all common columns for all vehicles such as miles per gallon, engine size, etc. The VEHICLE table might have subtype tables CAR and TRUCK, where only the CAR table has a column TRUNK.sub.-- SIZE and only the TRUCK table has a column for BED.sub.-- SIZE.
Traditional, paper-based entity relationship diagrams may require considerable effort to comprehend, since the lines connecting tables usually simply go to the edges of a table, not necessarily to the portion of the table being referenced. Furthermore, paper-based entity relationship diagrams may be difficult to maintain. For a complex database, the printed entity relationship diagram may easily be several feet long by several feet wide. As the database is changed, which may occur frequently, the corresponding entity relationship diagram must be updated, printed, and duplicated. Each version of the printed entity relationship diagram may potentially need to be distributed to a large number of people, such as the database architects, the database administrators, and software developers.
It would be desirable, therefore, to display an entity relationship diagram in component portions for ease in handling and viewing. It would further be advantageous if the display simplified comprehension of the relationships between tables. It would further be desirable to automatically update the entity relationship diagram from the corresponding database.